Release 10.1A: OpenEdge Development:
Progress Dynamics Basic Development

Normalization and table design

A Dynamics application will always benefit for well-designed tables. Keep in mind the basic principles of normalization when designing your tables:

A table column contains only one value. For example, a Name column in an Employee table will be easier to work with if it is separated into two columns: FirstName and LastName.
A table column avoids duplication and repetition of data. The Employee table should not have a Name column if it also has a First and Last column.
A table column does not store data that does not describe the table. All data bears a relationship to the concept captured by the table name. An Employee table that also contained data on Vendors will confuse your designs.
A table column does not contain redundant data. The Employee table should not contain three Joe Smith records if only one Joe Smith works at the company.
A table column is not necessary if it can be derived from other columns. For example, an Employee table might only need to store Zip Code for U.S. addresses, if City and State can be derived from a Zip Code lookup table.

When you begin developing an application using well-designed, normalized database tables, you get immediate benefits:

Straightforward relationships makes it easy to reuse standard code.
If the dataset for a particular task can be defined with simple, meaningful queries, the overall development will be less.
Eliminating excess data allows you to easily update and manage the data.

All in all, good table design means less procedural code and less customization of standard code blocks.

Note: The choice between using database triggers or other procedures for logic of this kind, and other aspects of organizing your application logic, is discussed in Chapter 11, " Building Advanced Business Logic in a Progress Dynamics Application."

The following sections describe a few other important table design guidelines.